This invention relates to video-on-demand systems which send multiple streams of video data from a video server to respective viewers; and more particularly, this invention relates to processes for sending trick-mode video streams with a high performance from the video server.
In the prior art, one early video-on-demand system is described in U.S. Pat. No. 5,583,561 which is entitled “MULTI-CAST DIGITAL VIDEO DATA SERVER USING SYNCHRONIZATION GROUPS”. An overview of this system is shown in FIG. 1 of patent '561. There, multiple video programs are stored in a video library 10 which is coupled to a video server 12; and, the video server 12 is coupled through a network interface circuit 18 to a plurality of video display devices 24 and 26 on a network 20.
To receive a particular video at a particular display device, a request is sent by a viewer via a telephone to the video server. In response to the viewer's request, the video server 12 retrieves the requested video from the video library 10. Thereafter, the retrieved video is sent as a stream of video data from the video server 12 thru the network interface circuit 18 to the viewer on the network 20 who requested to see it.
One method for sending the stream of video data from the video server 12 thru the network interface circuit 18 is disclosed in detail in the above-referenced patent '561. Also, alternative methods are disclosed in—1) pending patent application Ser. No. 09/318,987 which is entitled “SCALEABLE VIDEO SYSTEM HAVING SHARED CONTROL CIRCUITS FOR SENDING MULTIPLE VIDEO STREAMS TO RESPECTIVE SETS OF VIEWERS”, 2) pending patent application Ser. No. 09/796,816 which is entitled “METHOD OF MOVING VIDEO DATA THRU A VIDEO-ON-DEMAND SYSTEM WHICH AVOIDS PAGING BY AN OPERATING SYSTEM”, and 3) pending patent application Ser. No. 09/881,903 which is entitled “QUICK-START METHOD OF MOVING VIDEO DATA THRU A VIDEO-ON-DEMAND SYSTEM”. The details in the above patent and patent applications are herein incorporated by reference.
All of the above patents and application focus on how to send a video stream to a viewing device at the video's normal viewing speed. By comparison, a trick-mode video stream is sent to a viewing device to show the video at a speed which is faster or slower than the normal viewing speed. For example, trick-mode video streams enable a video to be viewed in modes such as fast-forward, fast-reverse, slow-forward, slow-reverse, and freeze frame.
One method for generating a trick-mode video stream from a normal video stream that is stored in a memory within the video server (herein method #1) is as follows. Initially, the video server transfers selected spaced-apart portions of the normal video stream from the memory into a buffer. Next, the video server modifies various items in the selected pictures in the buffer, and new items are also added to the buffer. The video server repeats the above steps until the buffer is filled; and then, it writes the content of the buffer into the memory as a portion of the trick-mode video stream.
However, a major problem with the above method #1 is that it requires a very large amount of video data to be read from/written to the memory; and that in turn inherently limits the speed with which the method can be carried out. To illustrate this problem, consider now a specific example where the normal video stream is stored in the memory in a standard MPEG-2 video format.
With the MPEG-2 format, the normal video stream is comprised of a sequence of “I-Pictures”, “P-Pictures”, and “B-Pictures”. I-Pictures are encoded independently to get compression without reference to other pictures. P-Pictures are encoded with respect to previous I-Pictures or P-Pictures to thereby get additional compression. B-Pictures are encoded with respect to previous and future I-Pictures or P-Pictures to get even more compression.
Typically, the entire sequence of the I-Pictures, P-Pictures, and B-Pictures are encoded in groups of twelve to fifteen pictures, with each group containing a single I-Picture. An example of one such group is B(0), B(1), I(2), B(3), B(4), P(5), B(6), B(7), P(8), B(9), B(10), P(11), B(12), P(13), P(14). In this group, the number in parenthesis indicates the picture display order, or “temporal reference”.
In the normal MPEG-2 video stream, the pictures of each group are sent in an out-of-order series such as I(2), B(0), B(1), P(S), B(3), B(4), P(8), B(6), B(7), P(11), B(9), B(10), P(14), B(12), B(13). Also, each picture may be partitioned into several parts that are sent as separate transmission segments; and, each segment may include various additional items, such as timing data, control data, etc.
When a trick-mode video stream is generated from a normal MPEG-2 video stream by the above method #1, the following memory reads and memory writes must occur. Initially, selected I-Picture segments in the normal video stream are read from memory and are transferred into the buffer. Next, one or more of the above additional items in the I-Picture segments are modified in the buffer; and, new items are also added to the buffer. These steps are repeated until the buffer is full; and then, the buffer is written into the memory.
Suppose now that the average number of bytes in the video segments for one complete I-Picture is “NI”; the average number of bytes that are modified in one I-Picture segment is “NM”; and the average number of bytes that are added is “NA”. Then, to perform the above steps, the total number of reads and writes on average is NI+NM+NA+NI+NA.
Some realistic average numerical values of NI, NM, and NA for a 4-megabit per second MPEG-2 video stream respectively are 50 KB, 100B, and 20 KB. Thus, with these values, the total number of bytes that are read/written by the above method #1 is 140,100 bytes. This large number of reads and writes severely limits the overall performance of the video server because they must be performed over and over for as long as a single trick-mode video stream needs to be sent. Also, these reads and writes must be repeated for each different trick-mode video stream; and that greatly limits the maximum number of trick-mode video streams which can be sent concurrently to separate viewing devices.
Accordingly, a primary object of the present invention is to address and overcome the above problem.